Techniques for adjusting computing device sleep states

ABSTRACT

This application relates to techniques that adjust the sleep states of a computing device based on proximity detection and predicted user activity. Proximity detection procedures can be used to determine a proximity between the computing device and a remote computing device coupled to the user. Based on these proximity detection procedures, the computing device can either correspondingly increase or decrease the amount power supplied to the various components during either a low-power sleep state or a high-power sleep state. Additionally, historical user activity data gathered on the computing device can be used to predict when the user will likely use the computing device. Based on the gathered historical user activity, deep sleep signals and light sleep signals can be issued at a time when the computing device is placed within a sleep state which can cause it to immediately enter either a low-power sleep state or a high-power sleep state.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a divisional of U.S. patent application Ser.No. 15/720,783, entitled “TECHNIQUES FOR ADJUSTING COMPUTING DEVICESLEEP STATES,” filed Sep. 29, 2017, set to issue Oct. 13, 2020 as U.S.Pat. No. 10,802,568, which claims the benefit of U.S. ProvisionalApplication No. 62/514,743, entitled “TECHNIQUES FOR ADJUSTING COMPUTINGDEVICE SLEEP STATES,” filed Jun. 2, 2017, the contents of which areincorporated herein by reference in their entirety for all purposes.

This application is also related to U.S. patent application Ser. No.15/996,372, entitled “TECHNIQUES FOR ADJUSTING COMPUTING DEVICE SLEEPSTATES,” filed Jun. 1, 2018, published as U.S. Publication No.2018/0348844 on Dec. 6, 2018, the content of which is incorporatedherein by reference in its entirety for all purposes.

FIELD OF INVENTION

The described embodiments relate generally to sleep state adjustmentprocedures for computing devices. More particularly, the presentembodiments relate to techniques that involve adjusting sleep states fora computing device based on a proximity of a remote device and/orlearned user behavior.

BACKGROUND

In a given conventional computer system, the system can transitionbetween a number of different sleep states based on a duration for whichthe system remains in a generalized sleep state. For example, as thesleep duration increases, the system can increasingly lower or switchoff power to different internal components in an effort to promoteenergy efficiency. For instance, after a first period of sleep timeelapses, one system component is powered off, after a second period ofsleep time elapses, another system component is powered off, and so on.

Notably, the cost of implementing the foregoing energy saving measurescan often result in the system requiring a considerable amount time tore-enter into a fully-functional/awake computing state. In particular,additional time costs can be involved in reanimating the differentinternal components when the system is abruptly required to reenter intoan awake state (e.g., when a laptop lid is opened, when a power buttonis pressed, etc.). Consequently, this can be unpleasant for users asthey are required to sit and wait for seemingly long periods of time fortheir systems to enter into an awake state after extended periods ofdisuse.

SUMMARY OF INVENTION

Accordingly, representative embodiments set forth herein disclosetechniques for adjusting the sleep states of a computing device based onproximity detection and predicted user activity in a manner that allowsit to efficiently use power resources. In particular, the techniquesinvolve (1) adjusting sleep states of a computing device based on aproximity of a remote computing device and (2) adjusting sleep statesbased on historical user activity through the scheduling of deep andlight sleep signals.

One embodiment sets forth a method for adjusting sleep states of a firstcomputing device based on a proximity of a second computing device. Inparticular, the method involves, at the first computing device, a firststep of detecting the proximity of the first computing device relativeto the second computing device. Next, the method involves, provided thefirst computing device is operating within a high-power sleep state andis not proximate to the second computing device, the step of causing thefirst computing device to enter into a low-power sleep state relative tothe high-power sleep state. Finally, the method involves the step of,provided the first computing device is operating within the low-powersleep state and is proximate to the second computing device, causing thefirst computing device to enter into the high-power sleep state.

One embodiment sets forth a method to adjust sleep states based onhistorical user activity. In particular, the method involves the firststep of gathering the historical user activity on the computing devicewhen the computing device is in an awake state. Next, the methodinvolves scheduling, based on the historical user activity, a deep sleepsignal and a light sleep signal to occur when the computing device iswithin a sleep state, in which the deep sleep signal causes thecomputing device to enter into a low-power sleep state, and the lightsleep signal causes the computing device to enter into a high-powersleep state. Finally, the method involves the step of issuing the deepsleep signal and the light sleep signal in accordance with thescheduling when the computing device is within the sleep state.

Other embodiments include a non-transitory computer readable storagemedium configured to store instructions that, when executed by aprocessor included in a computing device, cause the computing device tocarry out the various steps of any of the foregoing methods. Furtherembodiments include a computing device that is configured to carry outthe various steps of any of the foregoing methods.

Other aspects and advantages of the invention will become apparent fromthe following detailed description taken in conjunction with theaccompanying drawings that illustrate, by way of example, the principlesof the described embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure will be readily understood by the following detaileddescription in conjunction with the accompanying drawings, wherein likereference numerals designate like structural elements.

FIG. 1 illustrates an overview of a system that can be configured toperform the various techniques described herein, according to someembodiments.

FIGS. 2A-2B illustrate example scenarios of sleep state adjustmentprocedures performed using proximity detection, according to someembodiments.

FIG. 3A illustrates example user activity detection procedures used toperform sleep state adjustment procedures, according to someembodiments.

FIGS. 3B-3D illustrate graphical representations of data gathered andanalyzed to perform sleep state adjustment procedures, according to someembodiments.

FIG. 4 illustrates example scenarios of selectively enabling anddisabling sleep state adjustment procedures, according to someembodiments.

FIG. 5 illustrates a first method for adjusting sleep states of acomputing device based on a proximity of a remote computing device,according to some embodiments.

FIG. 6 illustrates a second method for adjusting sleep states based onhistorical user activity, according to some embodiments.

FIG. 7 illustrates a detailed view of a computing device that can beused to implement the various techniques described herein, according tosome embodiments.

DETAILED DESCRIPTION

Representative applications of methods and apparatus according to thepresent application are described in this section. These examples arebeing provided solely to add context and aid in the understanding of thedescribed embodiments. It will thus be apparent to one skilled in theart that the described embodiments can be practiced without some or allof these specific details. In other instances, well-known process stepshave not been described in detail in order to avoid unnecessarilyobscuring the described embodiments. Other applications are possible,such that the following examples should not be taken as limiting.

In the following detailed description, references are made to theaccompanying drawings, which form a part of the description and in whichare shown, by way of illustration, specific embodiments in accordancewith the described embodiments. Although these embodiments are describedin sufficient detail to enable one skilled in the art to practice thedescribed embodiments, it is understood that these examples are notlimiting such that other embodiments can be used, and changes can bemade without departing from the spirit and scope of the describedembodiments.

The embodiments described herein set forth techniques for adjustingsleep states of a computing device to reduce the amount of time itspends re-entering into a fully-functional/awake computing state. Causesfor such unnecessary delays are often due to the considerable amount oftime the computing device spends powering on each of the variouscomponents of the computing device that were previously placed intosleep states. The embodiments described herein can avoid these delays byusing proximity detection procedures to determine if a user is nearbyand, thus, likely to use the computing device by detecting the presenceof a remote computing device coupled to the user. The describedembodiments can correspondingly increase power supplied to the variouscomponents during a low-power sleep state to place it in position foruse in the likely event that the user uses the computing device againgiven the user's proximity to it.

Using proximity detection procedures, the embodiments can also determineif a user is not near the computing device based on a lack of proximitybetween the computing device and the remote computing device. In thisfashion, the embodiments can also correspondingly decrease powersupplied to the various components during a high-power sleep state tobetter conserve power resources given the unlikely event that the userwill re-engage in its use based on the lack of proximity.

The embodiments described herein also use historical user activity datagathered on the computing device to predict when the user will likelyuse the computing device. Based on historical user activity datagathered over a period of time, the described embodiments can schedulethe issuance of deep sleep signals and light sleep signals when thecomputing device is within a sleep state which can cause it toimmediately enter either a low-power sleep state or a high-power sleepstate.

A more detailed description of the various techniques described herein,and the manner in which they can be implemented, is provided below inconjunction with FIGS. 1, 2A-2B, 3A-3D, and 4-7.

FIG. 1 illustrates a high-level overview 100 of a computing device 102that can be configured to perform the various techniques describedherein. As shown in FIG. 1, the computing device 102 can include aprocessor 104, a volatile memory 106 (e.g., a Random-Access Memory(RAM)), and a non-volatile memory 118 (e.g., a storage device). It isnoted that a more detailed breakdown of example hardware components thatcan be included in the computing device 102 is illustrated in FIG. 7,and that these components are omitted from the illustration of FIG. 1merely for simplification purposes. For example, the computing device102 can include additional non-volatile memories (e.g., solid statedrives, hard drives, etc.), other processors (e.g., a multi-core centralprocessing unit (CPU)), and so on. According to some embodiments, anoperating system (OS) 108 can be loaded into the volatile memory 106,where the OS 108 can execute a variety of applications that collectivelyenable the various techniques described herein to be implemented. Asdescribed in greater detail herein, such applications can include aproximity detector 110, a power controller 112, a user activity detector114, and a learning engine 116.

According to some embodiments, the proximity detector 110 can enable thecomputing device 102 to detect remote computing devices that are withina threshold distance relative to the computing device 102. For example,the proximity detector 110 can measure a signal strength of signalsemitted from a remote computing device, e.g., signals periodically sentby the remote computing device, signals sent by the remote computingdevice in response to signals sent by the computing device 102, and soon. It is noted that any form of signal can be utilized, e.g., Bluetoothsignals, Near Field Communication (NFC) signals, WiFi signals, cellularsignals, and so on. Accordingly, the proximity detector 110 can (1)detect the presence of a remote computing device, and (2) calculate anestimate of a distance of the remote computing device relative tocomputing device 102. In this manner, and as described in greater detailherein, the foregoing functionalities can be utilized to adjust thesleep states of the computing device 102 to provide faster wakeup timeswhile promoting power efficiency.

Additionally, and according to some embodiments, the proximity detector110 can be configured to detect and analyze device identification dataassociated with remote computing devices when carrying out the foregoingsignal transmission procedures. For example, the proximity detector 110can be configured to identify specific Media Address Control (MAC)addresses, Internet Protocol (IP) addresses, etc., of nearby remotecomputing devices so that “foreign” remote computing devices—i.e.,remote computing devices that are detectible by, but not known to thecomputing device 102—can be disregarded when carrying out the sleepstate adjustment procedures described herein. According to someembodiments, the device identification data can represent a group ofremote computing devices that are associated with the computing device102. For example, a common user account (e.g., a cloud user account) canassociate the computing device 102 with the group of remote computingdevices. In this manner, as remote computing devices areassociated/disassociated with the common user account, the computingdevice 102 can continue to identify relevant nearby remote computingdevices and respond according to the techniques described herein.

Additionally, it is noted that the embodiments described herein are notlimited to only utilizing signal transmissions between the computingdevice 102 and remote computing devices when attempting to detectproximity conditions. On the contrary, and according to someembodiments, the proximity detector 110 can be configured to analyzedata collected through any sensors that can be utilized to identify whenremote computing devices—or users themselves—are proximate to thecomputing device 102. The sensors can include, for example, biometricsensors, motion sensors, audio/video sensors, and so on, that enable thecomputing device 102 to identify when to both (1) prepare the computingdevice 102 to enter into an awake state (when proximity is detected),and (2) cause the computing device 102 to enter into a deeper sleepstate (when proximity is not detected).

Accordingly, the proximity detector 110 can be utilized to identifyproximity conditions (or lack thereof) in which the different sleepstates of the computing device 102 can be adjusted. According to someembodiments, the different sleep states of the computing device can beadjusted by the power controller 112, which can be configured toincrease/decrease/cease the power supplied to various componentsresident on computing device 102 as it operates within the differentsleep states. As described in greater detail herein, these sleep statescan include, for example, a high-power sleep state, a mid-power sleepstate, a low-power sleep state. It is noted that the foregoing sleepstates are merely exemplary, and that any number of sleep states can beimplemented on the computing device 102 to achieve a desired level ofsleep state granularity. According to some embodiments, the powercontroller 112 can be configured to send/receive control signals frompower resource components (not illustrated in FIG. 1) that are residenton the computing device 102. For example, the power controller 112 cansend control signals to power resource components that are capable ofadjusting the operating modes of internal components that can include,for example, processor components, memory components, communicationscomponents, bus components, and the like.

As described in greater detail herein, the power controller 112 can be aprimary component within the computing device 102 that is configured tomanage the sleep states of the computing device 102 based on datagathered/analyzed by the proximity detector 110, the user activitydetector 114, and/or the learning engine 116. For example, with respectto the proximity detector 110, this component can be utilized by thepower controller 112 to identify when a remote device is nearby or awayfrom the computing device 102, and accordingly adjust the sleep statesof the computing device 102. With respect to the user activity detector114/learning engine 116, these components can gather/learn user activityassociated with the computing device 102, and be utilized by the powercontroller 112 to appropriately adjust the sleep states of the computingdevice 102. For example, the power controller 112 can determine that auser is likely to awaken the computing device 102 during an anticipatedtime window (e.g., when the computing device 102 is in a low or midsleep state), and correspondingly send control signals to power resourcecomponents to heighten the sleep state of the computing device based on(e.g., prior to or during) the anticipated time window. In a similarfashion, the power controller 112 can also determine that a user is notlikely to awaken the computing device 102 for a predicted time period(e.g., when the computing device 102 is in a high or mid sleep state),and correspondingly send control signals to power resource components tolower the sleep state of the computing device 102 based on (e.g., priorto or during) the predicted time period.

According to some embodiments, the power controller 112 can issue theabove-described control signals to cause the computing device 102 toenter into any desired sleep state level (e.g., low, mid, high, etc.).For example, the power controller 112 can issue control signals toincrease or decrease the current sleep state of the computing device 102by a single level. In another example, the power controller 112 cangenerate control signals that cause the current sleep state of thecomputing device 102 to transition into a highest-power sleep state or alowest-power sleep state while bypassing intermediate sleep states (ifany). According to some embodiments, the highest-power sleep state canrepresent a state in which the computing device 102 operates prior toentering into an awake (i.e., fully-operable) state. Conversely, thelowest-power sleep state can represent a sleep state in which thecomputing device 102 operates period to entering into a suspended (e.g.,hibernated) state. Again, it is noted that the foregoing sleep statesare merely exemplary, and that any number of sleep states—as well as anylevel of shift in sleep states—can be implemented within the computingdevice 102.

Additionally, the power controller 112 also includes the functionalityto selectively enable and disable the sleep adjustment procedures underappropriate scenarios. For instance, according to some embodiments, thepower controller 112 can include the functionality to detect scenariosin which a remote computing device is generally within the vicinity ofcomputing device 102 and frequently transitions between satisfying andnot satisfying a proximity distance threshold value (e.g., a signalstrength) during a threshold period of time (e.g., a period of a fewminutes). In this scenario, the computing device 102 might transitionbetween the highest-power and lowest-power sleep states (when the sleepadjustment procedures are enabled), which can result inperformance/power efficiency degradation. However, as noted above, thepower controller 112 can be configured to identify situations in whichit is prudent to disable the sleep adjustment procedures to ensure thatthe performance/power efficiency gains afforded by the techniquesdescribed herein remain intact.

Additionally, and as noted above, the user activity detector 114 canenable the computing device 102 to identify scenarios in which thecomputing device 102 is likely/not likely to be utilized by a user.According to some embodiments, the user activity detector 114 caninclude the functionality to detect instances in which a user engagescomputing device 102 in some manner. For example, the user activitydetector 114 can record or capture a number of different user inputtypes capable of being received and processed by the computing device102. For instance, user activity detector 114 can detect a userproviding input to computing device 102 through a wired or wirelesskeyboard, a wired or wireless mouse, a wired or wireless gamepad, atouch sensitive panel coupled to computing device 102, a touch-sensitivedisplay coupled to computing device 102, and the like. In otherexamples, the user activity detector 114 can detect motion of thecomputing device 102 that indicates that a user likely will want toawaken the computing device 102 (e.g., when being pulled out of acarrying case and positioned onto a user's lap). In yet other examples,the user activity detector 114 includes the functionality to detectinstances in which a user engages computing device 102 through remotecomputing mechanisms, such as secure shell (“SSH”) connections made tothe computing device 102.

Additionally, the user activity detector 114 also includes thefunctionality to generate historical user activity data based ondetected user activities, which can be analyzed by the learning engine116 to establish meaningful observations about user behaviors. Accordingto some embodiments, the learning engine 116 can be configured tocorrelate instances of user interactions with computing device 102 withspecific time periods to identify typical user usage patterns. The userusage patterns can be gathered over time during a particular thresholdtime period (e.g., hours, days, months, years, etc.) and utilized by thepower controller 112 to implement the user-behavior based sleep stateadjustment techniques described herein.

Accordingly, FIG. 1 provides a high-level overview of differenthardware/software architectures that can be implemented by computingdevice 102 in order to carry out the various techniques describedherein. A more detailed breakdown of these techniques will now beprovided below in conjunction with FIGS. 2A-2B, 3A-3D, and 4-7. Itshould be noted that in the embodiments and examples set forth herein, auser is generally physically coupled the remote computing devicesdiscussed.

FIGS. 2A-2B illustrate example scenarios of sleep state adjustmentprocedures performed using proximity detection, according to someembodiments. FIG. 2A depicts two computing devices, a local computingdevice (e.g., computing device 102) and a remote computing device (e.g.,remote computing device 204). In some embodiments, the computing device102 can be implemented as, for example, a desktop computer, portableelectronic device (e.g., laptop computer, audio device, entertainmentdevice, and so on), wireless hand-held devices (e.g., mobile phone,pager, and the like), wireless wearable devices capable of wirelesslytransmitting digital information (e.g., electronic watch devices), andso on. The remote computing device 204 can be a device capable oftransmitting wireless signals capable of being received and measured forsignal strength by the computing device 102. In some embodiments, theremote computing device 204 can include at least some portion of thefunctionality described herein with respect to the computing device 102.

FIG. 2A also depicts a scenario in which the computing device 102 wasremoved from a low-power sleep state and placed within a high-powersleep state after detecting the presence of the remote computing device204 nearby. The computing device 102 can selectively activate orinitialize its proximity sensing features to gather proximity data whilethe computing device 102 operates within an awake state, as well asvarious sleep states (e.g., high-power sleep states, low-power sleepstates, and so on). The proximity detection capabilities of theproximity detector 110 (depicted as installed within the computingdevice 102) can enable the computing device 102 to detect objects withina detectable distance relative to the computing device 102 based on apre-determined proximity distance threshold value (e.g., valuecorresponding to a proximity radius 202).

According to some embodiments, values below the pre-determined proximitydistance threshold value can be an indication of weaker signal detectionthereby causing the computing device 102, via the proximity detector110, to determine that there is no remote computing device nearby. Inthis fashion, values above the pre-determined proximity distancethreshold value can be an indication of stronger signal detection,thereby causing the computing device 102 to determine that there is aremote computing device nearby. For instance, as illustrated by theproximity detection procedures 200 in FIG. 2A, the remote computingdevice 204 is detected by the computing device 102 as being within theproximity radius 202.

Given this proximity, signals (e.g., Bluetooth signals, RSS signals,WiFi signals, and the like) emitted from the remote computing device 204are of sufficient strength such that the computing device 102 can detectboth the presence of the remote computing device 204 and also accuratelygauge how far away the remote computing device 204 is relative to thecomputing device 102. In this scenario, given the close proximity of thecomputing device 102 and the remote computing device 204, the computingdevice 102 can determine that a user (not depicted in FIG. 2A) is morelikely to use the computing device 102 within a pre-determined period oftime and correspondingly sends control signals, via the power controller112 (not depicted in FIG. 2A) to power resource components that increasethe amount of power supplied to components resident within the computingdevice 102.

For instance, circuitry included within the computing device 102 can besufficiently powered in order to respond to any commands issued by anearby user. According to some embodiments, the computing device 102 caninclude audio signal circuitry that can be sufficiently powered toperform voice-activated operations. For example, in one use case, thecomputing device 102 can be configured, through installed software(e.g., Apple Inc.'s Siri®), to perform various operations in response tovoice commands received via one or more microphones coupled to thecomputing device 102. In another use case, increased sound levelsdetected by the one or more microphones can be indicative of doorsclosing or other hints that a user is proximate to the computing device102 and, thus, likely to engage in use of the computing device 102within a short period of time.

Indeed, by enabling the power controller 112 to selectively issuecontrol signals in the manner described herein, the circuitry within thecomputing device 102 can be immediately removed from a previouslow-power sleep state and placed within a high-power sleep state. Inthis fashion, the computing device 102 can operate in a manner thatallows it to anticipate user usage while also conserving power resourcesin a high-power sleep state rather than remaining in a low-power sleepstate which would require more time to restore the computing device 102to an awake state.

FIG. 2B depicts a scenario in which the computing device 102 was removedfrom a high-power sleep state and placed within a low-power sleep stateafter not detecting the presence of the remote computing device 204nearby. As illustrated by the proximity detection procedures 206 in FIG.2B, the remote computing device 204 is not detected by the computingdevice 102, via the proximity detector 110 (depicted as installed withinthe computing device 102), due to the fact that the remote computingdevice 204 is not within the proximity radius 202. Given the lack ofproximity, any signals emitted from the remote computing device 204 arenot strong enough for the computing device 102 to detect the presence ofthe remote computing device 204. In this scenario, given the lack ofproximity between the computing device 102 and the remote computingdevice 204, the computing device 102 can determine that a user is lesslikely to use the computing device 102 within the pre-determined periodof time. Accordingly, the computing device 102 correspondingly sendscontrol signals, via the power controller 112 (not depicted in FIG. 2B)to power resource components that decrease the amount of power suppliedto components resident within the computing device 102.

By issuing control signals in this manner, the computing device 102 canbe immediately placed within low-power sleep state and removed from ahigh-power sleep state. In this fashion, the computing device 102 canoperate in a manner that allows it to conserve more power resources,relative to a high-power sleep state, by operating within a low-powersleep state rather than unnecessarily remaining in a high-power sleepstate during a time in which a user is unlikely to engage the computingdevice 102 in any kind of user activity. In addition to adjusting sleepstates based on detecting the proximity of a remote computing devicerelative to the computing device 102 (as described herein), theembodiments described herein can also analyze user usage patterns tomake intelligent sleep state adjustment determinations, which will nowbe described.

FIG. 3A illustrates an example of user activity detection proceduresperformed during a sleep state adjustment determination, according tosome embodiments. As depicted during user activity detection procedures300 performed in FIG. 3A, the computing device 102 can detect useractivity 308, via the user activity detector 114 (depicted as installedwithin the computing device 102), which can be in the form of a numberof different user input types capable of being received and processed bythe computing device 102. For instance, the computing device 102 candetect a user providing input to the computing device 102 through awired or wireless keyboard (e.g., keyboard 302 a). In another example,the computing device 102 can detect a user providing input to thecomputing device 102 through a wired or wireless mouse (e.g., mouse 302b).

In another example, the computing device 102 can detect a user providinginput to the computing device 102 through a wired or wireless gamepad(e.g., gamepad 302 c). In yet another example, the computing device 102can detect a user providing input to the computing device 102 through atouch sensitive panel (e.g., panel 302 d) or touch-sensitive display.According to some embodiments, the computing device 102 can detect auser providing input to the computing device 102 remotely through secureshell (“SSH”) computing procedures (not depicted in FIG. 3A) or similarprocedures. It should be noted that the embodiments of the presentinvention are not limited to the user input types illustrated in FIG. 3Aand can include additional types of user input capable of being receivedand processed by the computing device 102.

With reference now to the graphical illustration depicted in FIG. 3B,while the computing device 102 operates within an awake state, thecomputing device 102 (via the learning engine 116) can be configured toanalyze stored data related to historical user activity involving theuse of the computing device 102. Historical user activity data (e.g.,stored historical user activity data 310) stored by the computing device102 can include user usage patterns performed on the computing device102 over a period of time (e.g., several days, months, years, and soon). User usage patterns can include activities or events in which theuser directly engages the computing device 102 and that occur with acertain degree of regularity in a manner that allows the computingdevice 102 to accurately predict a future occurrence of the particularuser activity. User activities can include the use of the various inputdevices described herein (e.g., user activity 308) as well as inputsreceived by the computing device 102 remotely (e.g., SSH procedures).According to some embodiments, historical user activity data can bestored within memory resident on computing device 102.

FIG. 3B depicts a scenario in which the learning engine 116 analyzeddata gathered/stored over the course of several months. It should benoted that the user activity level (UAL) depicted in FIG. 3B can be ameasurement in the frequency of user-initiated activity performed on thecomputing device 102. Using the stored historical user activity data 310depicted in FIG. 3B, the learning engine 116 can determine a user'sgeneral usage pattern of the computing device 102 during any given day(e.g., usage pattern between 9 am and 2 pm, which corresponds with times312, 314, 316, 318, 320, and 322, respectively). For example, asillustrated in FIG. 3B, the stored historical user activity data 310 canbe processed in a manner such that the computing device 102 canaccurately determine times of the day in which user activity involvingthe use of the computing device 102 typically begins to decrease (e.g.,time 312 which corresponds to approximately 9 am) as well as when usagetypically begins to increase (e.g., time 320 which corresponds toapproximately 1 pm). As will be described in greater detail herein, thestored historical user activity data 310 can be used to schedule theissuance of both “light” sleep signals and “deep” sleep signals toadjust a current sleep state level of the computing device 102.

FIG. 3C depicts a graphical illustration of how sleep state operationsare performed by the computing device 102, prior to the enactment of thesleep state adjustment procedures described herein. As depicted in thecurrent sleep state schedule determinations 324 in FIG. 3C, thecomputing device 102 can enter a number of different computing states,“S0” to “S2,” during times 312, 314, 316, 318, 320, and 322. State (S0)can represent a fully-functional or “awake” computing state in which thecomputing device 102 operates in a fully-operational mode such that itsresident components are sufficiently powered to fully perform theirrespective functions.

Sleep state (S1) can represent a sleep state in which the computingdevice 102 operates within a low-power mode such that componentsresident within the computing device 102 are supplied with a decreasedamount of power relative to an awake computing state. Placing thecomputing device 102 within sleep state (S1) causes the computing device102 to save a smaller amount of power relative to sleep state (S2)(which will discussed in greater detail herein) while allowing thecomputing device 102 to be restored to an awake state in a shorterperiod of time relative to sleep state (S2).

Sleep state (S2) can represent a deeper sleep state or “standby” mode inwhich the computing device 102 operates within an even lower power moderelative to sleep state (S1) such that components residing within thecomputing device 102 are supplied with minimal power such that thecomputing device 102 approaches being completely placed within “poweredoff” state. Placing the computing device 102 within sleep state (S2)allows the computing device 102 to achieve the highest possible powersavings relative to sleep state (S1) at the cost of requiring a greateramount of time to restore the computing device 102 to an awake staterelative to sleep state (S1).

As depicted in FIG. 3C during the T1 time period, the computing device102 operates within the (S0) computing state. During a later phase ofthe T1 period, the computing device 102 can experience a period ofinactivity in which a user may not be actively engaging the computingdevice 102. Thus, during this later phase of the T1 period, a sleepstate policy executed by the computing device 102 can execute localsleep operations such that the computing device 102 begins to operatewithin the (S1) sleep state towards the end of the T1 period.

During the T2 time period, the computing device 102 continues to operatewithin the (S1) sleep state. During this period, the computing device102 saves a smaller amount of power relative to the (S2) sleep stateduring the T2 time period while enabling the computing device 102 to beable to restore itself to the (S0) computing state in a shorter periodof time relative to the (S2) sleep state. During a later phase of the T2period, the computing device 102 can experience a period of continuedinactivity in which a user may still not be engaging the computingdevice 102. Thus, during this later phase of the T2 period, the sleepstate policy executed by the computing device 102 can further engagelocal sleep operations such that the computing device 102 begins tooperate within a “deeper” sleep state, (S2), towards the end of the T2period.

During the T3 time period, the computing device 102 continues to operatewithin the (S2) sleep state. During this period, the computing device102 saves a highest amount of power relative to the (S1) sleep state atthe expensive of the computing device 102 requiring a greater amount oftime to restore itself to the (S0) computing state relative to theamount of time that would be required when it was operating within the(S1) sleep state. As illustrated in FIG. 3C, during a later phase of theT3 period, the computing device 102 can begin to experience a period ofrenewed user activity in which the user begins to re-engage thecomputing device 102 once again. Thus, during this later phase of the T3period, the sleep state policy executed by the computing device 102 caninitialize operations that remove the computing device 102 from the (S2)sleep state and restore itself to an awake (S0) computing state at thebeginning of the T4 period.

FIG. 3D depicts a graphical illustration of how the computing device 102can use stored historical user activity data to schedule and issue deepsleep and light sleep signals that adjust sleep states, according tosome embodiments. Using, the learning engine 116 (not depicted in FIG.3D), the computing device 102 can correlate typical user usage patternsgathered from the historical user activity data accumulated over aperiod of time (e.g., stored historical user activity data 310 in FIG.3B) with the scheduling of deep sleep signals (e.g., deep sleep signal328) and light sleep signals (e.g., light sleep signal 332).

As depicted by the sleep adjustment procedures 326 illustrated in FIG.3D, the deep sleep and light sleep signals can be issued, via the powercontroller 112, in accordance with a scheduled time. As depicted in FIG.3D, the power controller 112 can schedule the issuance of the deep sleepsignal 328 at a time, time 330 (e.g., 10:30 am in FIG. 3B), which occursbetween times 314 (e.g., 10 am in FIG. 3B) and 316 (e.g., 11 am in FIG.3B). Accordingly, time 330 can be recognized as a time in which thecomputing device 102 typically experiences decreased user activity(based on historical user activity data gathered) and in which thecomputing device 102 typically operates within a (S1) sleep state. Assuch, with further reference to FIG. 3D, the deep sleep signal 328 canbe issued by the power controller 112 to immediately decrease the amountof power supplied to one or more components of the computing device 102,thereby causing the computing device 102 to immediately enter the (S2)computing state at time 330.

By placing the computing device 102 into the (S2) sleep state in thismanner, the computing device 102 can reside in a lowest possible sleepstate (e.g., “standby” mode) for a larger portion of the T2 period,whereas prior to the scheduling of deep sleep signal 328, the computingdevice 102 would have continued to operate within the (S1) computingstate for the entire duration of the T2 period (as depicted by the solidlines between the times 314 and 316 in FIG. 3D). In this fashion,through the use of the scheduling procedures described herein, thecomputing device 102 can use historical user activity data gathered overtime to accurately predict a time period in which the user will likelynot use the computing 102 and intelligently decrease the amount of powerit can save during that time period.

Additionally, as illustrated in FIG. 3D, the power controller 112 canschedule the issuance of the light sleep signal 332 at time 334 (e.g.,12:30 pm in FIG. 3B), which occurs between times 318 (e.g., 12 pm inFIG. 3B) and 320 (e.g., 1 pm in FIG. 3B). Accordingly, time 334 can berecognized as a time in which the computing device 102 typicallyexperiences continued inactivity (based on historical user activity datagathered) and a time in which the computing device 102 typically remainsin the (S2) sleep state. As such, with further reference to FIG. 3D, thelight sleep signal 332 can be issued to instruct resident powerresources of the computing device 102 to immediately increase the amountof power supplied to one or more components of computing device 102,thereby causing the computing device 102 to immediately enter the (S1)sleep state at time 334.

By placing the computing device 102 into the (S1) sleep state in thismanner, the computing device 102 can operate in a high-power sleep statefor larger portion of the T3 period, whereas prior to the scheduling ofthe light sleep signal 332, the computing device 102 would havecontinued to operate within the S2 computing state for the entireduration of the T3 period (as depicted by the solid lines between times318 and 320 in FIG. 3D). In this fashion, through the use of thescheduling procedures described herein, the computing device 102 can usehistorical user activity data gathered over time to accurately predict atime period in which the user will likely use the computing 102. Theissuance of the light sleep signal 332 advantageously increases theamount of power supplied to the computing device 102 at point just priorto the predicted user activity. Accordingly, the computing device 102can be quickly restored to the (S0) computing state and becomefully-functional in less time.

FIG. 4 depicts procedures in which computing device 102 can selectivelyenable and disable sleep state adjustment procedures in accordance withembodiments of the present invention. As described herein, the computingdevice 102 can detect scenarios in which a remote computing device isgenerally within the vicinity of computing device 102 and oscillatesbetween satisfying and not satisfying a proximity distance thresholdvalue (e.g., proximity radius 400) during a pre-determined period oftime (e.g., period of a few minutes). By selectively enabling anddisabling the sleep state adjustment procedures described herein, thecomputing device 102 can be able to advantageously detect scenarios inwhich a user coupled to remote computing device 402 is generally withinthe vicinity of computing device 102 and is incidentally crossing theproximity radius 400 for only a brief period of time.

For example, a user holding remote computing device 402 may bemomentarily walking away from the computing device 102 (e.g., a laptop)at Time 1 to grab coffee in a nearby room and incidentally crosses theproximity radius 400 during the process, only to return to using thecomputing device 102 a short time thereafter during Time 2. In anotherexample, the user may be performing a number of tasks that require theuser holding the remote computing device 402 to return and leave thelocation of computing device 102 and number of times. Accordingly, thecomputing device 102 can be configured to prevent itself from adjustingsleep states (e.g., (S1) sleep state, (S2) sleep state) in response toidentifying that the remote computing device 402 transitions from beingproximate to not proximate within a threshold period of time. Accordingto some embodiments, the computing device 102 can be configured toprevent itself from adjusting sleep states in response to identifyingthat remote computing device 402 transitions from being proximate to notproximate to the computing device 102 a number of times within athreshold period of time.

FIG. 5 illustrates a method 500 for adjusting sleep states of acomputing device based on a proximity of a remote computing device tothe computing device, as described herein according to some embodiments.As shown in FIG. 5, the method 500 can be implemented by the computingdevice 102, and begins at step 502, where the computing device 102determines whether it is in a sleep state. Sleep states can include, forexample and as described herein, low-power sleep states and high-powersleep states. If the computing device 102 determines that it is in asleep state, the computing device 102 next determines whether a remotecomputing device is proximate to the computing device 102, as describedin step 504. Otherwise, the computing device 102 determines that it isnot in a sleep state and the computing device 102 can continuemonitoring to determine if it is in a sleep state. If the computingdevice 102 determines that it is not in a sleep state, it can operatewithin an awake state due to detected user activity involving the use ofthe computing device. Once user activity is no longer detected, thecomputing device can proceed to step 502 to determine whether it iscurrently in a sleep state.

At step 504, the computing device 102 can determine whether a remotecomputing device is proximate to the computing device 102. Given thatthe computing device 102 determined that is currently within a sleepstate at step 502, the computing device 102 then makes determinations asto whether it should enter a high-power sleep state or a low-power sleepstate based on proximity to a remote computing device. If the computingdevice 102 determines that a remote computing device is proximate to thecomputing device 102, then the computing device 102 next determineswhether it is currently in a low-power sleep state, as described in step506. Otherwise, the computing device 102 determines whether it iscurrently in a high-power sleep state, as described in step 510.

At step 506, the computing device determines whether it is currently ina low-power sleep state. Given that the computing device 102 determinedthat a remote computing device is proximate to the computing device 102at step 504, the computing device 102 then makes determinations as towhether it should enter a high-power sleep state. If the computingdevice 102 determines it is currently in a low-power sleep state, thenthe computing device 102 enters into a high-power sleep state, asdescribed in step 508. Otherwise, the computing device 102 nextdetermines whether it is currently in a high-power sleep state, asdescribed in step 510.

At step 508, the computing device 102 enters into a high-power sleepstate. Given that the computing device 102 determined that the remotecomputing device is proximate to the computing device 102 at step 504and was in a low-power sleep state at step 506, the computing device 102determines that a user coupled to the remote computing device is morelikely to use the computing device 102 within a pre-determined period oftime and therefore sends control signals to power resource componentsthat increase the amount of power supplied to components resident withinthe computing device 102.

At step 510, the computing device 102 determines whether it is currentlyin a high-power sleep state. Given that the computing device 102determined that a remote computing device is not proximate to thecomputing device 102 at step 504, the computing device 102 then makesdeterminations as to whether it is currently operating within ahigh-power sleep state. If the computing device 102 is in a high-powersleep state, the computing device 102 enters into a low-power sleepstate, as described in step 512. Otherwise, the computing device 102determines whether it is in a sleep state, as described in step 502.

At step 512, the computing device 102 enters into a low-power sleepstate. Given that the computing device 102 determined that a remotecomputing device is not proximate to the computing device at step 504and that it is not currently operating within a high-power sleep stateat step 510, the computing device 102 determines that a user coupled tothe remote computing device 102 is less likely to use the computingdevice within a pre-determined period of time and therefore sendscontrol signals to power resource components that decrease the amount ofpower supplied to components resident within the computing device. Inaddition, the computing device proceeds to make determinations as towhether it is currently in a sleep state, as described in step 502.

FIG. 6 illustrates a method 600 for adjusting sleep states based onhistorical user activity, as described herein according to someembodiments. As shown in FIG. 6, the method 600 can be implemented by acomputing device 102, and begins at step 602, where the computing device102 determines whether it is in an awake state. If the computing device102 determines that it is in an awake state, the computing device 102next gathers data of historical user activity performed on the computingdevice 102, as described in step 604. Otherwise, the method 600determines that the computing device 102 is not in an awake state andwaits for the computing device to enter an awake state.

At step 604, the computing device 102 gathers data related to historicaluser activity performed on it. The historical user activity data is usedby the computing device 102 to accurately determine times of the day inwhich user activity involving the use of the computing device 102typically begins to decrease as well as when usage typically begins toincrease so that the scheduled deep sleep and light sleep signalscorrespondingly increase and decrease power supplied during the sleepstate at the appropriate times. At step 606, the computing device 102schedules a deep sleep signal and a light sleep signal based on thehistorical user activity data gathered.

At step 608, the computing device 102 determines whether it is in asleep state. Given that the computing device 102 scheduled a deep sleepsignal and a light sleep signal at step 606, the computing device 102waits for the next sleep state to issue the signals in accordance withthe determined schedule. If the computing device 102 is in a sleepstate, then the computing device 102 next determines whether it detectedrecognizable user usage patterns, as described in step 610. Otherwise,the computing device 102 continues to gather data of historical useractivity performed on it, as described in step 604.

At step 610, the computing device 102 determines whether it detectedrecognizable user patterns. Given that the computing device 102 hasdetermined that is currently within a sleep state, the computing device102 determines whether recognizable user usage patterns are detectedbased on the historical user activity data gathered during step 604 Ifit detected recognizable user usage patterns, then the computing device102 issues the deep sleep signal and the light sleep signal inaccordance with the schedule, as described in step 612. Otherwise, thecomputing device 102 continues to gather data of historical useractivity performed on it, as described in step 604.

FIG. 7 illustrates a detailed view of a computing device 700 that can beused to implement the various components described herein, according tosome embodiments. In particular, the detailed view illustrates variouscomponents that can be included in the computing device 102 illustratedin FIG. 1. As shown in FIG. 7, the computing device 700 can include aprocessor 702 that represents a microprocessor or controller forcontrolling the overall operation of the computing device 700. Thecomputing device 700 can also include a user input device 708 thatallows a user of the computing device 700 to interact with the computingdevice 700. For example, the user input device 708 can take a variety offorms, such as a button, keypad, dial, touch screen, audio inputinterface, visual/image capture input interface, input in the form ofsensor data, and so on. Still further, the computing device 700 caninclude a display 710 that can be controlled by the processor 702 todisplay information to the user. A data bus 716 can facilitate datatransfer between at least a storage device 740, the processor 702, and acontroller 713. The controller 713 can be used to interface with andcontrol different equipment through an equipment control bus 714. Thecomputing device 700 can also include a network/bus interface 711 thatcouples to a data link 712. In the case of a wireless connection, thenetwork/bus interface 711 can include a wireless transceiver.

As noted above, the computing device 700 also include the storage device740, which can comprise a single disk or a collection of disks (e.g.,hard drives), and includes a storage management module that manages oneor more partitions within the storage device 740. In some embodiments,storage device 740 can include flash memory, semiconductor (solid state)memory or the like. The computing device 700 can also include aRandom-Access Memory (RAM) 720 and a Read-Only Memory (ROM) 722. The ROM722 can store programs, utilities or processes to be executed in anon-volatile manner. The RAM 720 can provide volatile data storage, andstores instructions related to the operation of applications executingon the computing device 102, including the proximity detector 110, thepower controller 112, the user activity detector 114, and the learningengine 116.

The foregoing description, for purposes of explanation, used specificnomenclature to provide a thorough understanding of the describedembodiments. However, it will be apparent to one skilled in the art thatthe specific details are not required in order to practice the describedembodiments. Thus, the foregoing descriptions of specific embodimentsare presented for purposes of illustration and description. They are notintended to be exhaustive or to limit the described embodiments to theprecise forms disclosed. It will be apparent to one of ordinary skill inthe art that many modifications and variations are possible in view ofthe above teachings.

What is claimed is:
 1. A method for adjusting sleep states based onhistorical user activity, the method comprising, at a computing device:gathering the historical user activity on the computing device when thecomputing device is in an awake state; scheduling, based on thehistorical user activity, a deep sleep signal and a light sleep signalto occur when the computing device is within a sleep state, wherein thedeep sleep signal causes the computing device to enter into a low-powersleep state, and the light sleep signal causes the computing device toenter into a high-power sleep state; and issuing the deep sleep signaland the light sleep signal in accordance with the scheduling while thecomputing device is within the sleep state.
 2. The method of claim 1,wherein the low-power sleep state is a lowest possible sleep staterelative to a powered-off state for the computing device, and thehigh-power sleep state is a highest power sleep state relative to theawake state for the computing device.
 3. The method of claim 1, whereingathering the historical user activity comprises learning user usagepatterns performed on the computing device.
 4. The method of claim 3,wherein the deep sleep signal is scheduled in accordance with the userusage patterns indicating that the computing device will not be utilizedfor a threshold period of user inactivity.
 5. The method of claim 3,wherein the light sleep signal is scheduled in accordance with the userusage patterns indicating that the computing device will be utilized fora threshold period of user activity.
 6. The method of claim 5, whereinthe light sleep signal is scheduled in advance of the threshold periodof user activity commencing.
 7. The method of claim 1, wherein causingthe computing device to enter into the low-power sleep state comprisesat least one of: deactivating an increased number of components withinthe computing device, and decreasing an amount of power supplied to onemore of the components included in the computing device.
 8. Anon-transitory computer readable storage medium configured to storeinstructions that, when executed by a processor included in a computingdevice, cause the computing device to adjust sleep states based onhistorical user activity, by carrying out steps that include: gatheringthe historical user activity on the computing device when the computingdevice is in an awake state; scheduling, based on the historical useractivity, a deep sleep signal and a light sleep signal to occur when thecomputing device is within a sleep state, wherein the deep sleep signalcauses the computing device to enter into a low-power sleep state, andthe light sleep signal causes the computing device to enter into ahigh-power sleep state; and issuing the deep sleep signal and the lightsleep signal in accordance with the scheduling while the computingdevice is within the sleep state.
 9. The non-transitory computerreadable storage medium of claim 8, wherein the low-power sleep state isa lowest possible sleep state relative to a powered-off state for thecomputing device, and the high-power sleep state is a highest powersleep state relative to the awake state for the computing device. 10.The non-transitory computer readable storage medium of claim 8, whereingathering the historical user activity comprises learning user usagepatterns performed on the computing device.
 11. The non-transitorycomputer readable storage medium of claim 10, wherein the deep sleepsignal is scheduled in accordance with the user usage patternsindicating that the computing device will not be utilized for athreshold period of user inactivity.
 12. The non-transitory computerreadable storage medium of claim 10, wherein the light sleep signal isscheduled in accordance with the user usage patterns indicating that thecomputing device will be utilized for a threshold period of useractivity.
 13. The non-transitory computer readable storage medium ofclaim 12, wherein the light sleep signal is scheduled in advance of thethreshold period of user activity commencing.
 14. The non-transitorycomputer readable storage medium of claim 8, wherein causing thecomputing device to enter into the low-power sleep state comprises atleast one of: deactivating an increased number of components within thecomputing device, and decreasing an amount of power supplied to one moreof the components included in the computing device.
 15. A computingdevice configured to adjust sleep states based on historical useractivity, the computing device comprising a processor configured tocause the computing device to carry out steps that include: gatheringthe historical user activity on the computing device when the computingdevice is in an awake state; scheduling, based on the historical useractivity, a deep sleep signal and a light sleep signal to occur when thecomputing device is within a sleep state, wherein the deep sleep signalcauses the computing device to enter into a low-power sleep state, andthe light sleep signal causes the computing device to enter into ahigh-power sleep state; and issuing the deep sleep signal and the lightsleep signal in accordance with the scheduling while the computingdevice is within the sleep state.
 16. The computing device of claim 15,wherein the low-power sleep state is a lowest possible sleep staterelative to a powered-off state for the computing device, and thehigh-power sleep state is a highest power sleep state relative to theawake state for the computing device.
 17. The computing device of claim15, wherein gathering the historical user activity comprises learninguser usage patterns performed on the computing device.
 18. The computingdevice of claim 17, wherein the deep sleep signal is scheduled inaccordance with the user usage patterns indicating that the computingdevice will not be utilized for a threshold period of user inactivity.19. The computing device of claim 17, wherein the light sleep signal isscheduled in accordance with the user usage patterns indicating that thecomputing device will be utilized for a threshold period of useractivity.
 20. The computing device of claim 19, wherein the light sleepsignal is scheduled in advance of the threshold period of user activitycommencing.